maybe it makes sense to allow the first param of euclid to be an array, so ":" notation can be used, allowing the last param to be optional:

s("bd").euclid("3:8")
// is the same as
s("bd").euclid(3,8)
// and
s("bd").euclid("3:8:1")
// is the same as
s("bd").euclidRot(3,8,1)

this would eliminate the need to use / learn euclidRot. Legato could be achieved with the second param being negative:

s("bd").euclid("3:-8")
// is the same as
s("bd").euclidLegato(3,8)
// and
s("bd").euclid("3:-8:1")
// is the same as
s("bd").euclidLegatoRot(3,-8,1)

we can still merge these shortcuts, but I think having a more flexible euclid function makes the other ones more or less obsolete. edit: I generally find myself using euclid with structs more often:

s("bd")
.struct("x(3,8) x*2")

this would also benefit if a negative second param would make the thing legato

maybe it makes sense to allow the first param of euclid to be an array, so ":" notation can be used, allowing the last param to be optional:

s("bd").euclid("3:8")
// is the same as
s("bd").euclid(3,8)
// and
s("bd").euclid("3:8:1")
// is the same as
s("bd").euclidRot(3,8,1)

this would eliminate the need to use / learn euclidRot. Legato could be achieved with the second param being negative:

s("bd").euclid("3:-8")
// is the same as
s("bd").euclidLegato(3,8)
// and
s("bd").euclid("3:-8:1")
// is the same as
s("bd").euclidLegatoRot(3,-8,1)

we can still merge these shortcuts, but I think having a more flexible euclid function makes the other ones more or less obsolete. edit: I generally find myself using euclid with structs more often:

s("bd")
.struct("x(3,8) x*2")

this would also benefit if a negative second param would make the thing legato

I really like the idea of using the array pattern syntax with negativve numbers. Maybe the second array param being rotate though would be more useful? unless you are doing really weird stuff with rhythms. here is another thought:

s("bd").euclid("5:2 -3:1", 8)

the first half of the cycle would be 5 with a rotation of 2, the second half would be 3 with a rotation of 1, but backwards. This way you could get a huge variety of rhythms with just a few numbers in a pattern. I think having a second argument for the division makes sense because it will probably stay stagnant for most use cases?

Maybe the second array param being rotate though would be more useful

I'd rather have the array params be the same order as the regular params, otherwise it can get confusing.. you could still do:

s("bd").euclid("5:8:2 -3:8:1")
// or
s("bd").euclid("[5 -3]:8:[2 1]")

Using an array for the first param is generally a good way to be able to call a function with optional args (which is not possible with curried functions otherwise). If the argument structure of the array notation is the same as for the regular function, you don't have to remember more stuff

Hmm I see what you mean. tbh Ive never really played much with the euclid mininotation, it seems much more powerful. It could be cool also do be able to do x([5:2 -3:1], 8)
to easily get a wider variety of patterns (where the second param is rotate). Not sure how that would transfer to the euclid function though... tbh it seems kinda redundant with the euclid mininotation being an option